home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Gigantic Games 2
/
Gigantic Games 2.iso
/
pc
/
_q_
/
quickmoney
/
qm.doc
next >
Wrap
Text File
|
1994-12-23
|
8KB
|
139 lines
11/3/92
Ben Campbell
8 Montana Ave
Christchurch 4
New Zealand
QUICK MONEY - A two player game of reflexes, cunning, strategy and explosions.
The Requirements:
Any model Amiga
Two input devices (mice or standard digital joysticks)
Two people (or one person with both homocidal and suicide tendancies)
The Scene:
A globally broadcast gameshow in which the contestants participate in
mechanised gladiator fights and try to destroy each other for cheap and tacky
prizes. The fights take place in purpose built arenas, the players controlling
their craft remotely (after all, this future society is very non-violent),
so nobody is physically hurt as such. Other targets are introduced into the
arenas, in the form of mechanical and biologically-engineered droids.
The Game:
If it moves, blast it. If it doesn't move, blast it anyway, just to be
on the safe side.
The game is presented as a split-screen-top-view of the arena - the top window
tracks player one, and the lower window, player two. Arenas are simple
mazes which scroll vertically to keep each player centered.
Each craft has a shield system, which is depleted by contact either with
droids, or with blasts fired by the other player. Shield status is represented
as a white bar next to the scores in the middle of the display. If a shield
reaches the zero mark, then the respective player is respectively very dead
indeed. Blowing away your opponent earns you bonus points. So needless
violence is strongly encouraged, as the overall winner of the game is the
player who has the most points when the game finishes.
Points may be earned by shooting and destroying droids or the other player.
Shields may be recharged by moving over a recharge area, which looks
like a yellowish/brownish squarish thing on the floor. However, recharging
involves 'buying' back shield energy with points, and so recharging is not
always a very good idea. If you have no points, you cannot recharge.
The contestants stay in the arena until they are either dead, or they have
destroyed a set number of droids, in which case the next arena is entered.
If one player dies, the other player continues playing until the end of the
current arena (survival is optional), so if you are in a losing position, you
have a chance to gain some more points. The scores are then compared and an
overall winner is declared.
Droids always originate from the area of floor marked with inward-pointing
arrows. Every level has one of these areas, and it is not a good idea to be
over one when a droid emerges, as your craft will take damage. However, a
good way to gain points is to stay near this area and pick off droids as they
come out. The other player will often have the same idea, and so you may find
yourself having to fight for this valuable territory.
There are a number of different droid types, each acting in a different way.
They get tougher (although not so very much brighter) and increase in numbers
as you progress.
The game really is quite simplistic, so it shouldn't take too long to get
the hang of it.
The ESCape key may be used to quit back to the title screen during play.
The Options:
On the title screen, there are three keyboard options with may be
played around with. F3 toggles the game between NTSC and PAL setup. The only
actual difference is that in NTSC a smaller area of the screen (200 lines as
opposed to 256) is used. Generally this will mean that you have less warning
of vertically-flying projectiles, but hey, don't worry, be happy. And duck.
If you have one of the later model Agnus chips (don't you just love all these
cool custom-chip names? I know of some people who wrote to Commodore giving
some very good reasons (which I won't go into here) as to why the 8520 CIA
chip should be called "Terry", but as it's not a custom CBM chip it sticks
with its old name of 8520, or alternatively "that
waste of silicon" by people who have had to replace them once or twice) you
can use one of those little programs to switch between 50Hz (PAL, 256 lines)
and 60Hz (NTSC, 200 lines) modes before you run the game. There are many of
these programs in public domain. If you play the game in 60Hz mode you
must remember to use F3 to switch to NTSC, or else the game will be a bit
out to lunch. You can also, pretty obviously, play the game in NTSC if you
are living (god help you) in a country which uses the NTSC TV system.
Playing the game in 60Hz mode makes it run about 10% faster than intended,
but really does give it just that little kick of speed, which is has a pretty
good feel to it. The downside is (as I said) that you see a smaller area
on screen.
F1 and F2 let you select either joystick or mouse control for each player.
In mouse mode, a little sphere appears about your craft, and may be moved
around with the mouse. The craft will go in the direction of the sphere. To
stop, move the sphere on top of the craft.
With joystick control, to go up, push up. To go down, push down. To go left,
push left. To go right, push right. You'll have to figure out diagonals for
yourselves. Firing (using the mouse or the joystick) is really pretty
intuitive, so you should be able to figure that out after a game or two
(or three or four - it will really depend on your hand-eye coordination and
manual dexterity).
Pressing ESCape on the title screen will exit from the game and bring
back the system.
The Code:
The game was written in assembly - Devpac source code included.
You may or may not be interested in the source code, but if you are, then I
hope you learn something useful from it. It is NOT a perfect example of the
best way to write a game, so feel free to laugh hysterically at it.
It takes over the system (ie disables multitasking) but leaves interrupts
running. Normally this doesn't really mean much, but, for example, it does
mean that you can do stuff like running soundtracker modules while the game
is going. The sound effects will conflict a bit with any modules you've got
going, as my sound effects routine is really pretty crap and directly
accesses the sound hardware (very non-amigaish) but then, so do most
module players so who really cares? I can't really see a bit of sound-conflict
stuffing things up too badly... (I haven't managed to GURU it yet!)
Apart from the sound, everything else is pretty system-legal as far as I can
tell, and should run ok on any Amiga. It was written on a stock A500, and
runs fine on a 3000, so I'm assuming that It'll work on anything inbetween.
I've made sure that the timing is all OK - ie it'll run at correct
speed even if your machine is at warp-factor 10. Of course, it won't take
advantage of any extra processor speed, but as I cannot afford an accelerator
board, I don't see why anyone else should have a good time. I have an idea
that the arena fadein/fadeout routine isn't properly timed, but it will
probably look better going faster anyway (and it won't affect the gameplay).
Also, The keyboard routine is pretty sad and pretty illegal, but it works,
doesn't hurt anything, and is really pretty minor anyway, so it stays (I
haven't managed to get this routine to GURU either).
Overall, the game is a lot more system-legal than many games I could mention,
including a lot of commercial games - games that conk out on anything other
than a standard-configuration 500. This really sucks, but the situation
is getting much better now that there are a number of other Amiga models
about.
Well, that is about all I have to say, so enjoy the game...
Ben.
"I thought he was going to shoot me so I shot him back first."